Virtual computing allows multiple virtual machines, each operating in their own isolated partition, to run on a host computer. The host computer has a virtualizer program that allows the host computer to execute the instructions of a virtual machine program. The host computer virtualizer program can also virtualize the hardware resources of the host machine for virtual machine use. The virtual machine or partition that is requesting hardware resources such as CPU, memory, I/O and disk space is ideally isolated from other partitions.
In a virtual machine environment, another partition only exists in the host computer system as a pure software representation of the operation of one specific hardware architecture. A virtualizer program acts as the interchange between the hardware architecture of the host machine and the instructions transmitted by the software (e.g., operating systems, applications, etc.) running within partitions of the virtual machine environment. In one virtual machine environment embodiment, the virtualizer program may include a virtual machine monitor (VMM) which is a software layer that runs directly above the host hardware, perhaps running side-by-side and working in conjunction with the host operating system, and which can virtualize all the resources of the host machine (as well as certain virtual resources) by exposing interfaces that are the same as the hardware the VMM is virtualizing. This virtualization enables the virtualizer (as well as the host computer system itself) to go unnoticed by operating system layers running above it. In a virtual machine environment, the multiple virtual machines impose performance requirements on the hardware resources of the host machine. It is desirable to keep one virtual machine separated from the other virtual machines as well as separated from the host. Separation or isolation of one virtual machine from another is useful to isolate errors and faults such that one virtual machine fault does not affect another virtual machine. Yet, in some configurations, it is desirable to have one virtual machine access host resources available to a second virtual machine. Therefore, isolation between partitions can become problematic.
Just as computers were made more stable by separating different applications into separate process address spaces, systems can be made even more stable by separating whole software stacks into separate virtual machine partitions. A whole software stack may be thought of as an operating system, including its plug-in modules, an application and any middleware between them. Given a system where one virtual machine or partition has exclusive access to a computer resource, then other partitions must access the “provider” partition in order to utilize or consume the computer resource. Systems that have such isolation partitions but are linked because some partitions are providers and some are consumers or clients of computer resources that have increased detrimental consequences if a fault appears in the provider partition. Under such fault conditions, a provider partition may be affected by faulty software and the dependent client partitions may likewise be affected. As a consequence of faulty software in the provider partition, the operating system hosting the provider functions as well as applications running in the provider partition may also be collaterally affected.
In the context of the present invention, a virtual service provider (VSP) provides input output (I/O) device-related resources to its virtual service clients. These I/O-device-related resources don't necessarily correspond directly to resources provided by a physical device. A virtual service provider consumes device I/O resources, as well as CPU and memory because it is software, and serves those resources to its virtual service clients. The resources consumed by a virtual service provider may come from a single device I/O software stack or from multiple device I/O software stacks. A virtual service provider can have one or more virtual service clients which may or may not exist in the same partition as the virtual service provider. A virtual service client (VSC) consumes the resources given to it by its virtual service provider. A VSC also consumes resources such as CPU and memory because the VSC is software. The virtual service client re-serves its granted resources to a software stack layer above it. In other words, the virtual service client can generally be thought of as the device drivers for the I/O-device-related resources that the virtual service provider offered.
FIG. 1 depicts a virtual computer system 100 and illustrates an example of an increased risk when using a partition system. In the example system 100, a first partition 110 contains a software stack 150. The software stack generally controls a computer resource such as hardware, software, bandwidth or other computer system resource. In the example embodiment of FIG. 1, the software stack is one that controls hardware. Virtual service provider (VSP) software 160 resides as part of the software stack 150. The software stack 150 may be logically separate from the VSP. In one embodiment, the VSP may be a client that sits on top of a stack. In this instance the hardware 165 is controlled via link 164 from the VSP 160. A second partition 120, a third partition 130 and a fourth partition 140 each have a virtual service client (VSC), 170, 180 and 190 respectively which rely on the VSP 160 in the first partition 110. A communications channel 145, such as a virtualization program or VMM provides a communications path from VSCs 170, 180 and 190 to the VSP 160. Therefore, any fault in the first partition 110 might cascade the through to the VSP 160 and may cause a four fold fault propagation since the VSC 170, 180 and 190 rely on the VSP 160 in partition 1.
FIG. 1 can be modified to contain multiple VSPs in the first partition such that each VSC in the system can share different VSPs in case one VSP fails. However, if a propagating fault appears in the first partition, then the multiple VSPs could be all be adversely affected and there is no real improvement in fault isolation. However, partitioning systems still has advantages.
In addition to reliability, the isolation that virtual machine partitioning enables can also be used to increase security. Components in the lower layers of a software stack, particularly those that run within the context of an operating system kernel, can often access any programs or data within a partition. If the services are moved to their own partition, then programs and data within them have a much smaller attack surface, as only the kernel-mode code within that specific partition can access them. As these partitions can be carefully constructed to contain only a small amount of the code that comprises the entire computing system, code that might be necessary on the whole may still be excluded from partitions that contain particularly sensitive data. Accordingly, thoughtful use of partitioning in computer system can have advantages.
Thus, there is a need for a system and method that can to allow the use of partitioned software elements to provide both isolation and fault tolerance in virtual computer systems. The present invention addresses the aforementioned needs and solves them with additional advantages as expressed herein.